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ABSTRACT 



A system which distributes requests among a plurality of 
network servers receives a request from a remote source at 
a first one of the network servers, and determines whether to 
process the request in the first network server. The request is 
processed in the first network server in a case that it is 
determined that the request should be processed in the first 
network server. On the other hand, the request is routed to 
another network server in a case that it is determined that the 
request should not be processed in the first network server. 

9 Claims, 6 Drawing Sheets 
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SYSTEM FOR BALANCING LOADS AMONG 
NETWORK SERVERS 

This application claims benefit of U.S. Provisional Ser. 
Nos. 60/071,039 filed Jan. 13, 1998 and 60/061,170 filed 
Oct. 6, 1997. 

BACKGROUND OF THE INVENTION 

The present invention is directed to a peer-to-peer load 
balancing system which is implemented in plural network 
servers. In particular, the invention is directed to a computer- 
executable module for use in network servers which enables 
each server to distribute loads among its peers based on a 
load currently being processed in each server and/or con- 
tents of the network requests. The invention has particular 
utility in connection with World Wide Web servers, but can 
be used with other servers as well, such as CORBA servers, 
ORB servers, FTP servers, SMTP servers, and Java servers. 

Network systems, such as the World Wide Web 
(hereinafter "WWW"), utilize servers to process requests for 
information. Problems arise, however, if one server becomes 
overloaded with requests. For example, if a server becomes 
overloaded, it may be unable to receive new requests, may 
be slow to process the requests that it has already received, 
and may yield server errors. 

Load balancing was developed to address the foregoing 
problems in the art. Briefly, load balancing involves distrib- 
uting requests among plural servers (e.g., different servers 
on a Web site) in order to ensure that any one server does not 
become unduly burdened. 

One conventional load balancing technique involves the 
use of a domain name server (hereinafter "DNS"), in par- 
ticular a "round-robin" DNS. This device, which typically 
operates on the network, is responsible for resolving uni- 
form resource locators or "URLs" (e.g., "www.foo.com") to 
specific IP addresses (e.g., 111.222.111.222). In this regard, 
a Web site having several servers may operate under a single 
URL, although each server is assigned a different IP address. 
A round-robin DNS performs load balancing by routing 
requests to these servers in sequential rotation based on their 
IP addresses. 

While round -robin DNSs can coarsely distribute loads 
among several servers, they have several drawbacks. For 
example, not all requests for connection to a Web site are 
necessarily received by a round-robin DNS. Rather, many 
requests will have been previously "resolved" by a DNS 
local to the requester and remote from the Web site (i.e., a 
"a remote DNS") or by the requester (i.e., the computer that 
issued the request on the WWW), In these cases, resolution 
is based on an address which has been cached in the remote 
DNS or the requestor, rather than by sequential rotation 
provided by the Web site's round-robin DNS. Due to this 
caching, load balancing may not be achieved to a satisfac- 
tory degree. 

DNS-based load balancing techniques have another sig- 
nificant drawback. In the event that a Web server fails (i.e., 
the Web server goes off-line), the Web site has no real-time 
mechanism by which to reroute requests directed to that 
server (e.g., by a remote DNS). Thus, a remote DNS with 
caching capabilities could continue to route requests to a 
failed server for hours, or even days, after the failure has 
occurred. As a result, a user's connection would be denied 
with no meaningful error message or recovery mechanism. 
This situation is unacceptable, particularly for commercial 
Web sites. 

As an alternative to the DNS-based load balancing tech- 
niques described above, some vendors have introduced 
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dedicated load balancing hardware devices into their sys- 
tems. One such system includes a device, called a proxy 
gateway, which receives all network requests and routes 
those requests to appropriate Web servers. In particular, the 

5 proxy gateway queries the servers to determine their respec- 
tive loads and distributes network requests accordingly. 
Responses from the servers are routed back to the network 
through the proxy gateway. Unlike the DNS-based schemes, 
all requests resolve to the IP address of the proxy server, 

10 thereby avoiding the risk that remote DNS caching or failed 
servers will inadvertently thwart access to the site. 

While proxy gateways address some of the fundamental 
problems of load balancing described above, they also have 
several drawbacks. For example, proxy gateways add 

15 latency in both the "request" direction and the "response" 
direction. Moreover, since the proxy gateway is, for all 
intents and purposes, the only way into or out of a Web site, 
it can become a bottleneck that limits the capacity of that site 
to the capacity of the proxy gateway. Moreover, the proxy 

20 gateway is also a single point of failure, since its failure 
alone will prevent access to the Web site. 

An IP redirector is a device similar to a proxy gateway 
which also performs load balancing. Like a proxy gateway, 
an IP redirector serves as a hub that receives and routes 

25 requests to appropriate servers based on the servers* loads. 
IP redirectors are different from proxy gateways in that IP 
redirectors do not handle responses to requests, but rather let 
those responses pass directly from the assigned Web servers 
to the requesters. However, IP redirectors suffer from many 

30 of the same drawbacks of the proxy gateways described 
above, particularly insofar as limiting the capacity of the 
Web site and preventing access to it as a result of failure of 
the IP redirector. 

35 Dedicated load balancers, such as proxy gateways and IP 
redirectors, also have drawbacks related to sensing loads in 
different Web servers. Using current technologies, a server 
can become busy in a matter of milliseconds. A load 
balancer, however, can only query various servers so often 

^ without creating undesirable overhead on the network and in 
the servers themselves. As a result, such load balancers often 
must rely on "old" information" to make load balancing 
decisions. Load balancing techniques which use this "old" 
information are often ineffective, particularly in cases where 

45 such information has changed significantly 

Dedicated load balancers, such as proxy gateways and IP 
redirectors, also have problems when it comes to electronic 
commerce transactions. In this regard, electronic commerce 
transactions are characterized by multiple sequential 

50 requests from a single client, where each subsequent request 
may need to refer to state information provided in an earlier 
request. Examples of this slate information include 
passwords, credit card numbers, and purchase selections. 
Problems with electronic commerce arise because an 

55 entire transaction must be serviced by one of plural network 
servers, since only that one server has the original state 
information. A load balancer therefore must identify the first 
request of a stateful transaction and keep routing requests 
from that requester to the same server for the duration of the 

60 transaction. However, it is impossible for the load balancer 
to know exactly where a transaction begins or ends, since the 
information in the request providing such indications may be 
encrypted (e.g., scrambled) when it passes through the 
dedicated load balancer. In order to maintain an association 

65 between one requestor and one server, dedicated load bal- 
ancers therefore use a mechanism referred to as a "sticky 
timer". More specifically, the load balancer infers which 
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request may be the start of a stateful transaction and then sets In other aspects of the invention, the receiving server 

a "sticky timer" of arbitrary duration (e.g., 20 minutes) determines whether to process a request based on its content, 

which routes all subsequent requests from the same e.g., its uniform resource indica tor ("URI"). By virtue of this 

requestor to the same Web server, and which renews the feature of the invention, it is possible to limit the server to 

"sticky timer" with each subsequent request. This method is 5 processing certain types of network requests, while routing 

easily bypassed and may unnecessarily defeat the load olherSt Alternatively, it is possible to direct particular 

balancing feature. requests to particular servers, which then may either process 

Thus, there exists a need for a load balancing technique or reroutc those requests based on loads currently being 

which is able to provide more accurate load balancing than handled by the servers 

the techniques described above, which is able to perform / . . 

accurate load balancing despite cached server addresses or 30 In other ^^ts of the invention, the receiving server 

"maintained" Web browser addresses, which is not a sig- determines which, if any, of its peer servers are off-line. The 

nificant bottleneck or source of single point failure, and then routes requests to its on-line peers and does not 

which is able to maintain the association between a client ™ uiG requests to its off-line peers. A server may also assume 

and a server in order to preserve state information required tne network identity (i.e., the IP address and/or URL) of an 

to complete an electronic commerce transaction. 15 off-line peer to insure that requests are serviced properly 

clTUUADV ^r, ™, c t kt\ no even if directed to an off-line peer by virtue of caching in a 

SUMMARY OF THE INVENTION remote QNS ^ ^ ^ {Q bo(h {[s 

The present invention addresses the foregoing needs by 0 wn identity and its assumed identity until the off-line peer 
providing, in one aspect, a plurality of network servers returns to on-line service. As a result, it is possible to reduce 
which directly handle load balancing on a peer-to-peer basis. 20 response errors resulting from requests being inadvertently 
Thus, when any of the servers receives a request, the server directed to off-line servers, 
either processes the request or routes the request to one of its . e , , 
peers-depending on their respective loads and/or on the In other ****** of * e invention, servers may be config- 
contents of the request. By implementing load balancing u red to recognize specific URIs which designate entry points 
directly on the servers, the need for dedicated load balancing „ for slateful transactions. A server so configured will not 
hardware is reduced, as are the disadvantages resulting from re - route re <l uests awa V from itself if they are related to a 
such hardware. Thus, for example, because each server has slaleful transaction conforming to the URI of the server, 
the capability to perform load balancing, access to a Web site Even URIs lhal arrive in encrypted requests will be 
managed by the server is not subject to a single point of decrypted by the server and, therefore, will be subject to 
failure. Moreover, requests tagged with IP addresses cached 30 intelligent interpretation in accordance with configuration 
by remote DNSs or the requestor itself are handled in the rules - As a result, an electronic commerce transaction corn- 
same way as other requests, i.e., by being routed among the P rised of multiple requests may be processed entirely on one 
load balancing-enabled servers. of P Iural 0nce the transaction is complete, as 

A network server according to a related aspect of the confirmed by comparing URI information to configuration 

invention exchanges information with its peers regarding 35 ^ subse ^ uent f re ^ s |f ^ a S ain be sub J ect 10 reroutin & 

their respective loads. This exchange may be implemented for the P ur P ose of load Wancu*. 

based on either a query/response or unsolicited multicasts Tnis bnef summary has been provided so that the nature 
among the server's peers, and may be encrypted or may of the invention may be understood quickly. A more corn- 
occur over a private communication channel. The exchange pl ete understanding of the invention can be obtained by 
may be implemented to occur periodically or may be trig- 40 rcference 10 the following detailed description of the pre- 
gered by a network event such as an incoming request. In a ^rred embodiments thereof in connection with the attached 
preferred embodiment of the invention, each server multi- drawings. 

casts its load information to its peers at a regular period (e.g., «mcc i^ce^niirrrnKr ^ctuc f»d a\i/tkt/-c 

crvi «„\ ti,', _ ■ j , . • „j„„„ m n „j „\Z BRIEF DESCRIPTION OF THE DRAWINGS 

500 ms). This period may be set in advance and subse- 
quently re-set by a user. In the preferred embodiment, the 45 A more complete understanding of the invention may be 
multicast message serves the dual purposes of exchanging attained by reference to the drawings, in which: 
load information and of confirming that a transmitting server FIG j is a diagram showing the topology of a Web site 
is still on-line. including the present invention; 

By virtue of the foregoing, and by virtue of the server FIG. 2, comprised of FIGS. 2A and 2B, is a flow diagram 

having nearly instantaneous information regarding its own 50 showi ess st for dislrib uting requests among vari- 

workload, the server is able to make routing determinations QUS seivers basc<j QQ thc , oads being handled b lhem; 

based on substantially up-to-date information. Thc most , . . ., , • <■ « <* . 

critical decision, i.e., whether to consider rerouting, is pref- u FIG " 3 *»' m ° re ^ etaded viewof a portion of the topology 

erably made based on the most current information available snoWQ lD nG - 1 rclalin 8 10 load balan cing; 

(i.e., based on a local server load provided nearly instanta- 55 FIG - 4 * a flow diagram showing process steps for 

neously from within the server and without any network dislributing requests among various servers based on the 

transmission latency). content of the requests; and 

In further aspects of thc invention, a server processes a FIG. 5 is a diagram showing the topology of a Web site 

received request directly when its load is below a first including the present invention and a proxy, 

predetermined level or if its load is above the first prede- 60 DETAILED DESCRIPTION OF THE 

termined level yet those of the server s peers are above a ILLUSTRATED EMBODIMENTS 
second predetermined level. Otherwise, the server routes the 

request to one of its peers. By equipping a site with multiples The present invention is directed to a system for imple- 

servers of this type, it is possible to reduce the chances that menting peer-to-peer load balancing among plural network 

one server will become overwhelmed with requests while 65 servers. Although the invention will be described in the 

another server of similar or identical capabilities remains context of the World Wide Web ("WWW"), and more 

relatively idle. specifically in the context of WWW servers, it is not limited 
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to use in this context. Rather, the invention can be used in comprise file servers which store a database for Web site 1. 

a variety of different types of network systems with a variety Back-end Web servers 27 and 29 may be used to access data 

of different types of servers. For example, the invention can files on mainframe 16 (or other similar computer) in 

be used in intranets and local area networks, and with response to requests from server cluster 6. Once such data 

CORBA servers, ORB servers, FTP servers, SMTP servers, 5 fii es have been accessed, mainframe 16 may then transmit 

and Java servers, to name a few. tnese fi ] cs back t0 serve,. cluslcr Alternatively, data on 

FIG. 1 depicts the topology of a Web site 1 which includes back-end Web servers 27 and 29 may be accessed directly 

the present invention, together with hardware for accessing from c i uster 6 without the aid of mainframe 16. 
that Web site from a remote location on the Internet. More 

specifically, FIG. 1 shows router 2, local DNS 4, server 1Q First Embodiment 

cluster 6 comprised of Web servers 7, 9 and 10, packet filter „ ¥ ^, ^ .„ „ , „ 

11, and internal network 12. A brief description of this FIG. 2 lUustrates process steps of the present invention for 

hardware is provided below ^ oaci balancing received network requests. To begin, in step 

Router 2 receives requests for information stored on Web ^201 a network request is received at a server, such as server 

site 1 from a remote location (not shown) on the Internet. 1S ^ show in FIG 3. This request may be reso ved by a remote 

Router 2 routes these requests, which typically comprise 35 DNS 00 Internet based on a cached IP address (e.g., 

URLs, to local DNS 4. Local DNS 4 receives a URL from rc <* ues * ^ 2 ' 3 , and , 4 > or > alle u rnat i v ^ ^ re< * ucst ma y * 

router 2 and resolves the domain name in the URL to a bv a *° cal round-robin DNS 4 (e.g., request 5). 

specific IP address in server cluster 6. ™ m > in #*f S202 > *™ \ determines a load (e.g., the 

Servercluster6ispartoftheuntrustedsegmentl4ofWeb 20 numbe ' and/or com P lc ^y of nctwork re 1 uests ) ' hal 11 15 
... r . *jo currently processmg, and the capacity remaining therein, 

site 1, to which access is relatively unrestricted. Server J r b r ' & 

cluster 6 is comprised of a plurality of servers, including Sle P s203 decides if lhe load currently being processed in 
servers 7, 9 and 10. Each of these servers is capable of server 7 exceeds a first predetermined level. In preferred 
retrieving information from internal network 12 in response embodiments of the invention, this predetermined level is 
to requests resolved by a remote DNS on the Internet or by « 50% f meaning that server 7 is operating at 50% capacity. Of 
local DNS 4. Included on each of servers 7, 9 and 10 is a course > the "mention is not limited to using 50% as the first 
microprocessor (not shown) and a memory (not shown) predetermined level. In this regard, a value for the first 
which stores process steps to effect information retrieval. In predetermined level may be stored in a memory on server 7, 
preferred embodiments of the invention, each memory is and ma y be reprogrammed periodically, 
capable of storing and maintaining programs and other data 30 If step S203 decides that server 7 is not processing a load 
between power cycles, and is capable of being repro- that exceeds the first predetermined level, flow proceeds to 
grammed periodically. An example of such a memory is a step S204. In step S204, the network request is processed in 
rotating hard disk. server 7, and a response thereto is output via the appropriate 
The memory on each server also stores a computer- channels. On the other hand, in a case that step S203 
executable module (i.e., a heuristic) comprised of process 35 determines that server 7 is processing a load that exceeds the 
steps for performing the peer-to-peer load balancing tech- first predetermined level, flow proceeds to step S205. 
nique of present invention. More specifically, server 7 Step S205 determines loads currently being processed by 
includes load balancing module 17, server 9 includes load server 7's peers (e.g., servers 9 and 10 shown in FIG. 3). In 
balancing module 19, and server 10 includes load balancing more detail, in step S205, load balancing module 17 corn- 
module 20. The process steps in these modules are execul- 40 pares its current load information with the most recent load 
able by the microprocessor on each server so as to distribute information provided by load balancing modules 19 and 20. 
requests among the Web servers. In more detail, the process These load balancing modules continuously exchange infor- 
steps include, among other things, code to receive a request mation regarding their respective loads, so that this infor- 
from a remote source at a first one of the Web servers (e.g., mation is instantly available for comparison. In the example 
server 7), code to determine whether to process the request 45 shown in FIG. 3, load balancing module 19 provides infor- 
in the first server, code to process the request in the first mation concerning the load currently being processed by 
server in a case that the determining code determines that the server 9, and load balancing module 20 provides informa- 
request should be processed in the first server, and code to tion concerning the load currently being processed by server 
route the request to another server (e.g., server 9) in a case 10. 

that the determining code determines that the request should 50 In step S206, load balancing module 17 determines 

not be processed in the first server. A more detailed descrip- whether the loads currently being processed by server 7's 

tion of the load balancing technique implemented by these peers are less than the load on server 7 by a differential 

process steps is provided below. exceeding a second predetermined level. In preferred 

Packet filler 11 comprises a firewall for internal network embodiments of the invention, this second predetermined 

12 (i.e., the trusted segment) of Web site 1. All transactions 55 level is 20%, which provides a means of assessing whether 

into or out of internal network 12 are conducted through servers 9 or 10 have at least 20% more of their capacities 

packet filter 11. In this regard, packet filter 11 "knows*' available than server 7. Of course, the invention is not 

which inside services of internal network 12 may be limited to using 20% as the second predetermined level. In 

accessed from the Internet, which clients are permitted this regard, as above, a value for the second predetermined 

access to those inside services, and which outside services 60 l eve l mav be stored in a memory on server 7, and may be 

may be accessed by anyone on internal network 12. Using reprogrammed periodically. 

this information, packet filter 11 analyzes data packets In a case that step S206 decides that server 7's peers (i.e., 

passing therethrough and filters these packets accordingly, servers 9 and 10) do not have 20% more of their capacity 

restricting access where necessary and allowing access available, flow proceeds to step S204. In step S204, the 

where appropriate. 65 network request is processed in server 7, and a response 

Internal network 12 includes mainframe 16 and back-end thereto is output via the appropriate channels. On the other 

Web servers 27 and 29. Back-end Web servers 27 and 29 hand, in a case that step S206 decides that at least one of 
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server 7's peers is processing a load that is less than the 
percent load on server 7 by the second predetermined level, 
flow proceeds to step S207. 

Step S207 determines which, if any, of the servers at Web 
site 1 are off-line based, e.g., on the load information 5 
exchange (or lack thereof) in step S205. A server may be 
off-line for a number of reasons. For example, the server 
may be powered-down, malfunctioning, etc. In such cases, 
the servers* load balancing modules may be unable to 
respond to a request from load balancing module 17 or 10 
otherwise be unable to participate in an exchange of 
information, thereby indicating that those servers are off- 
line. In addition, in preferred embodiments of the invention, 
the load balancing modules are able to perform diagnostics 
on their respective servers. Such diagnostics test operation 15 
of the servers. In a case that a server is not operating 
properly, the server's load balancing module may provide an 
indication to load balancing module 17 that network 
requests should not be routed to that server. 

Next, step S208 analyzes load information from on-line 20 
servers in order to determine which of the on-line servers is 
processing the smallest load. Step S208 does this by com- 
paring the various loads being processed by other servers 9 
and 10 (assuming that both are on-line). Step S209 then 
routes the network request to the server which is currently 25 
processing the smallest load. In the invention, routing is 
performed by sending a command from load balancing 
module 17 to a requestor instructing the requestor to send the 
request to a designated server. Thus, re-routing is processed 
automatically by the requestor software and is virtually 30 
invisible to the actual Internet user. 

Thereafter, that server processes the request in step S210. 
At this point, it is noted, however, that the invention is not 
limited to routing the request to a server that is processing 35 
the smallest load. Rather, the invention can be configured to 
route the request to any server that is operating at or below 
or predetermined capacity, or something similar such as, but 
not limited to, a round-robin hand-off rotation. 

FIG. 3 illustrates load distribution according to the 40 
present invention. More specifically, as noted above, server 
7 (more specifically, load balancing module 17) receives 
requests 1, 2, 3 and 4 resolved by network DNS 21 and 
request 5 via local DNS 4. Similarly, server 10 receives 
request 6 (i.e., a cached request) via local DNS 4. Any of 45 
these requests may be "boolanarked" requests, meaning that 
they are specifically addressed to one server. Once each load 
balancing module receives a request, it determines whether 
to process that request in its associated server or to route that 
request to another server. This is done in the manner shown 50 
in FIG. 2. By virtue of the processing shown in FIG. 2, load 
balancing modules 17, 19 and 20 distribute requests so that 
server 7 processes requests 1 and 2, server 9 processes 
requests 3 and 5, and server 10 processes requests 4 and 6. 

Second Embodiment 55 

In the second embodiment of the invention, load balanc- 
ing is performed based on a content of a network request, in 
this case a URL/URI. As noted above, a URL addresses a 
particular Web site and takes the form of 'Svww.foo.com". A 60 
URI, on the other hand, specifies information of interest at 
the Web site addressed by the URL. For example, in a 
request such as "www.foo.com/banking", "/banking" is the 
URI and indicates that the request is directed to information 
at the "foo" Web site that relates to "banking". In this 65 
embodiment of the invention, URIs in network requests are 
used to distribute requests among servers. 
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FIG. 4 is a flow diagram illustrating process steps com- 
prising this embodiment of the invention. To begin, in step 
S401, load balancing module 17 receives a request from 
either network DNS 21 or from local DNS 4 (see FIG. 3). In 
step S402, the load balancing module then analyzes the 
request to determine its content. In particular, load balancing 
module 17 analyzes the request to identify URIs (or lack 
thereof) in the request. 

Step S402 determines which servers) are dedicated to 
processing which URIs, and which server(s) are dedicated to 
processing requests having no URI. That is, in the invention, 
the load processing module of each server is configured to 
accept requests for one or more URIs, thus limiting the 
server to processing requests for those URIs. For example, 
load balancing module 17 may be configured to accept 
requests with a URI of "/banking", whereas load balancing 
module 19 may be configured to accept requests with a URI 
of "/securities". Which server processes which URI may be 
"hard-coded" within the server's loading balancing module, 
stored within the memory of each server, or obtained and 
updated via a dynamic protocol. 

In any event, in a case that step S403 decides that server 
17 is dedicated to processing LRIs of the type contained in 
the request (or no URI, whichever the case may be), flow 
proceeds to step S404. In step S404, the request is accepted 
by load balancing module 17 and processed in server 7, 
whereafter processing ends. On the other hand, in a case that 
step S403 decides that server 7 does not process URIs of the 
type contained in the request, flow proceeds to step S405. 
This step routes the request to one of server 7's peers that is 
dedicated to processing requests containing such URIs. 
Routing is performed in the same manner as in step S209 of 
FIG. 2. Once the request is received at the appropriate 
server, the load balancing module associated therewith 
accepts the request for processing by the server in step S406, 
whereafter processing ends. 

Third Embodiment 

The first and second embodiments of the invention 
described above can be combined into a single embodiment 
which routes network requests based on both a content of the 
request and loads being handled by the various servers. 
More specifically, in this embodiment of the invention, each 
load balancing module is configured to route a request to a 
server dedicated to a particular URI in a case that the server 
is operating at less than a predetermined capacity. In a case 
that the server is operating at above the predetermined 
capacity, the invention routes the requests to another server 
which can handle requests for the URI, but which is oper- 
ating at below the predetermined capacity. The methods for 
performing such routing are described above with respect to 
the first and second embodiments of the invention. 

Fourth Embodiment 

As noted above, the present invention reduces the need for 
a proxy gateway or similar hardware for distributing loads 
among various Web servers. It is noted, however, that the 
invention can be used with such hardware. FIG. 5 shows the 
topology of a Web site on which the present invention is 
implemented, which also includes proxy 26. 

In this regard, except for proxy 26, the features show in 
FIG. 5 are identical in both structure and function to those 
shown in FIG. 1. With respect to proxy 26, proxy 26 is used 
to receive network requests and to route those requests to 
appropriate servers. A load balancing module on each server 
then determines whether the server can process requests 
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routed by proxy 26 or whether such requests should be 
routed to one of its peers. The process for doing this is set 
forth in the first, second and third embodiments described 
above. 

5 

Fifth Embodiment 

This embodiment of the invention is directed to a system 
for maintaining an association between a requester and one 
of plural servers at a Web site when state information is used iq 
during an electronic transaction. 

More specifically, in accordance with this embodiment of 
the invention, a server at a Web site, such as server 7 shown 
in FIG. 1, is configured to recognize specific URIs (e.g., 
URIs that designate entry points for a stateful transaction 15 
relating to electronic commerce). In the case that one of 
these URIs is recognized, the server will not route subse- 
quent transactions away from that server, thereby ensuring 
that all such requests are processed by that server. Requests 
may again be re-routed from the server once a URI which 2 q 
matches a predetermined "configuration rule" is detected 
(e.g., when a transaction is complete). 

In preferred embodiments of the invention, wild card URI 
information may be used to designate a stateful path. For 
example, the hyperlink "http://www.foo.com/ banking/*" 25 
would mean that "http://www.foo.com/banking/" constitutes 
the entry point into a stateful transaction. Any request up to 
and including this point would be subject to potential 
re-routing. Any request further down this path would indi- 
cate that the requestor and the server are engaged in a 30 
stateful transaction and not subject to potential re-routing. 

The present invention has been described with respect to 
particular illustrative embodiments. It is to be understood 
that the invention is not limited to the above-described 
embodiments and modifications thereto, and that various 35 
changes and modifications may be made by those of ordi- 
nary skill in the art without departing from the spirit and 
scope of the appended claims. 

In view of the foregoing, what we claim is: 
1. A method of distributing requests among a plurality of *o 
network servers, the method comprising the steps of: 
receiving a request from a remote source at a first one of 

the network servers; 
executing a determining step in the first server, the deter- 45 
mining step for determining whether to process the 
request in the first network server; 
processing the request in the first network server in a case 
that the determining step determines that the request 
should be processed in the first network server; and 50 
routing the request to another network server in a case that 
the determining step determines that the request should 
not be processed in the first network server; 
wherein the determining step comprises the steps of: 
determining a load currently being processed by the 55 

first network server; and 
receiving information in the first network server from 
each of the other network servers, the information 
from each of the other network servers comprising 
information concerning a load currently being pro- 60 
cessed io each network server; 
wherein the determining step determines that the first 
network server should process the request in a case 
that (i) the load currently being processed in the first 
network server is below a first predetermined level, 65 
or (ii) the load currently being processed in the first 
network server is above the first predetermined level 
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and is above loads currently being processed by 
either of the other network servers by less than a 
second predetermined level; and 
wherein the determining step determines that the first 
network server should not process the request in a 
case that the load currently being processed in the 
first network server is above the first predetermined 
level and a load currently being processed in at least 
one of the other network servers is below the level of 
the first network server by at least the second pre- 
determined level. 

2. Computer-executable process steps stored on a 
computer-readable medium, the computer executable pro- 
cess steps comprising a server module which is installable in 
a plurality of network servers to distribute requests among 
the plurality of network servers, the computer-executable 
process steps comprising: 

code to receive a request from a remote source at a first 

one of the network servers; 
code, executable by the first server, to determine whether 

to process the request in that server; 
code to process the request in the first network server in 

a case that the determining code determines that the 

request should be processed in the first network server; 

and 

code to route the request to another network server in a 
case that the determining code determines that the 
request should not be processed in the first network 
server; 

wherein the determining code comprises: 

code to determine a load currently being processed by 
the first network server; and 

code to receive information in the first network server 
from each of the other network servers, the infor- 
mation from each of the other network servers com- 
prising information concerning a load currently 
being processed in each network server; 

wherein the determining code determines that the first 
network server should process the request in a case 
that (i) the load currently being processed in the first 
network server is below a first predetermined level, 
or (ii) the load currently being processed in the first 
network server is above the first predetermined level 
and is above loads currently being processed by 
either of the other network servers by less than a 
second predetermined level; and 

wherein the determining code determines that the first 
network server should not process the request in a 
case that the load currently being processed in the 
first network server is above the first predetermined 
level and a load currendy being processed in at least 
one of the other network servers is below the level of 
the first network server by at least the second pre- 
determined level. 

3. A network server which is capable of processing 
requests and of distributing the requests among a plurality of 
other network servers, the network server comprising: 

a memory which stores a module comprised of computer- 
executable process steps; and 

a processor which executes the process steps stored in the 
memory so as 

(i) to receive a request from a remote source at the 
network server, 

(ii) to determine whether to process the request in the 
network server by executing process steps so as (a) 
to determine a load currently being processed by the 
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first network server, and (b) to receive information in 
the first network server from each of the other 
network servers, the information from each of the 
other network servers comprising information con- 
cerning a load currently being processed in each 
network server; 

wherein the processor determines that the first net- 
work server should process the request in a case 
that (i) the load currently being processed in the 
first network server is below a first predetermined 
level, or (ii) the load currently being processed in 
the first network server is above the first prede- 
termined level and is above loads currently being 
processed by either of the other network servers 
by less than a second predetermined level; and 

wherein the processor determines that the first net- 
work server should not process the request in a 
case that the load currently being processed in the 
first network server is above the first predeter- 
mined level and a load currently being processed 
in at least one of the other network servers is 
below the level of the first network server by at 
least the second predetermined level; 

(iii) to process the request in the network server in a 
case that the processor determines that the request 
should be processed in the network server, and 

(iv) to route the request to another one of the plurality 
of network servers in a case that the processor 
determines that the request should not be processed 
in the network server. 

4. A method of distributing requests among a plurality of 
network servers, the method comprising the steps of: 

receiving a request from a remote source at a first one of 
the network servers; 

executing a determining step in the first server, the deter- 
mining step for determining whether to process the 
request in the first network server; 

processing the request in the first network server in a case 
that the determining step determines that the request 
should be processed in the first network server; and 

routing the request to another network server in a case that 
the determining step determines that the request should 
not be processed in the first network server; 

wherein the determining step comprises determining 
whether the request is related to a stateful transaction 
based on a UR1 in the request; and 

wherein (i) in a case that the request is related to a stateful 
transaction, determining that the request should be 
processed in the first network server, and (ii) in a case 
that the request is not related to a stateful transaction, 
determining if the request should be processed in the 
first network server. 

5. A method according to claim 4, wherein, in a case that 
the request is related to a stateful transaction, determining 
that at least a second request having a URI substantially the 
same as the URI of the request should be processed in the 
first network server. 

6. Computer-executable process steps stored on a 
computer-readable medium, the computer executable pro- 
cess steps comprising a server module which is installable in 
a plurality of network servers to distribute requests among 
the plurality of network servers, the computer-executable 
process steps comprising: 



code to receive a request from a remote source at a first 

one of the network servers; 
code, executable by the first server to determine whether 

to process the request in that server; 
code to process the request in the first network server in 

a case that the determining code determines that the 

request should be processed in the first network server; 

and 

10 code to route the request to another network server in a 
case that the determining code determines that the 
request should not be processed in the first network 
server; 

wherein the determining code comprises code to deter- 
35 mine whether the request is related to a stateful trans- 
action based on a URI in the request; and 
wherein (i) in a case that the request is related to a stateful 
transaction, the determining code determines that the 
20 request should be processed in the first network server, 
and (ii) in a case that the request is not related to a 
stateful transaction, the determining code determines if 
the request should be processed in the first network 
server. 

25 7. Computer-executable process steps according to claim 
6, wherein, in a case that the request is related to a stateful 
transaction, the code to determine determines that at least a 
second request having a URI substantially the same as the 
URI of the request should be processed in the first network 

30 server. 

8. A network server which is capable of processing 
requests and of distributing the requests among a plurality of 
other network servers, the network server comprising: 

a memory which stores a module comprised of computer- 
35 executable process steps; and 

a processor which executes the process steps stored in the 
memory so as 

(i) to receive a request from a remote source at the 
network server, 

40 (ii) to determine whether the request should be pro- 
cessed in the network server by determining whether 
the request is related to a stateful transaction based 
on a URI in the request; 

wherein (i) in a case that the request is related to a 
4 5 stateful transaction, the processor determines that 

the request should be processed in the network 
server, and (ii) in a case that the request is not 
related to a stateful transaction, the processor 
determines if the request should be processed in 
50 the network server; 

(iii) to process the request in the network server in a 
case that the processor determines that the request 
should be processed in the network server, and 

(iv) lo route the request to another one of the plurality 
55 of network servers in a case that the processor 

determines that the request should not be processed 
in the network server. 

9. A network server according to claim 8, wherein, in a 
case that the request is related to a stateful transaction, the 

60 processor determines that at least a second request having a 
URI substantially the same as the URI of the request should 
be processed in the network server. 
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